COMODI: On the Graphical User Interface 
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Abstract 

We propose a series of features for the graphical user 
interface ( GUI) of the Computational MOdule Integrator 
( COMODI) /T//?/. In view of the special requirements 
that a COMODI type of framework for scientific computing 
imposes and inspiring from existing solutions that provide 
advanced graphical visual programming environments, we 
identify those elements and associated behaviors that will 
have to find their way into the first release of COMODI. 



1 Introduction 

The computational MODule Integrator (COMODI) 
is an interdisciplinary collaboration for addressing the prob- 
lem of programming crisis in computational sciences (3). 
In Q], and jSj we have pointed out that there are at 
least three major problems plaguing computational software 
development and usage. Computational scientists tend to 
spend much of their time on writing code akeady written 
by others or trying to adapt existing code to local needs. 
On global scale this represents a costly lack of efficiency in 
exploiting human resources. Generally, low quality "home 
made" code is the only alternative to the anguish of search- 
ing, adapting and learning third party software; a process 
that further undermines the trust in external code. Finally, 
the irreproducibility of computer experiments by peers con- 
tributes again to the inefficiency of computational research 
by wasting the important advantage of virtuality over real 
experiments. We suggest that shifting towards a reuse ori- 
ented paradigm is necessary. In the same papers it is argued 
that a new software tool, language or standard is not suf- 
ficient. One has to explicitely aim at a large scale move- 
ment. However, the movement can only evolve around an 
OpenSource software solution that has to offer both on the 
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short and long run sufficient benefits so that the computa- 
tional community with deeply rooted programming tradi- 
tions would consider it as an alternative, and contribute ac- 
tively to its development. COMODI has the sole reponsibil- 
ity of igniting the process and then letting the events follow 
their natural course driven by the need and skill of the whole 
community. Therefore, it should not be a radically futuristic 
solution but rather a sturdy bridge between the old and new 
paradigm. During the ignition process, due to the lack of 
involvement of the community the task is especially chal- 
lenging. The needs that are best to target are difficult to 
identify and because of limited human resources the evolu- 
tionary trial and error approach that keeps OpenSource even 
though inefficient yet healthy is not admissible. Hence, the 
requirement analysis is the core issue of our investigation. 
In jl] we point out that the complete solution consists in 
two distinct parts. On one side there are tools used for con- 
verting regular code developed by component authors into 
a COMODI component, called the developer side, while on 
the other, there is a GUI-based graphical environment with 
underlying layers responsible for binding together compo- 
nents into arbitrarily complex computational projects dis- 
played as in figure|3 We term the latter as the user side. The 
two sides are clearly distinguishable by the tools that are 
used, the type of human activity that they presume and the 
required programming skills. Present paper focuses on the 
user side exploring its most prominent component, the GUI. 
As shown in HI, |4| and |5 1 the idiosyncrasy of COMODI 
is the special support provided to component authors. On 
the user side, GUIs for visual programming can look back 
to a relatively long evolution history. Several applications 
endowed with advanced features are in use today. Com- 
ing up with something that would assure a leading edge is 
more than a challenge and is off the point. However, the 
constituting premises of COMODI entail a series of special 
requirements set for the user interface. These, while do not 
make it a direct competitor in this segment, allow for us- 



ing present solutions as a valuable source of inspiration in 
its design process. Below we summarize a few important 
solutions worthwhile to consider. 

2 Visual programming in scientific comput- 
ing 

Though visual programming (VP) is not a widely spread 
phenomenon in computational science, the two have already 
made contact in a few areas |6|. Visualization of scientific 
data is clearly a leader in this respect. AVS (Advanced Visu- 
alization System) is one of the dominant commercial visual- 
ization packages available today. It provides modules and a 
user interface which allows these modules to be connected 
together into a flow chart. The compatibility of the inter- 
faces is checked automatically. Input data is processed se- 
quentially by the modules and usually an image is produced. 
AVS thus implements a data-flow paradigm of scientific vi- 
sualization. However, the developers of new AVS modules 
have an involved procedure to follow. OpenDX (Open Data 
eXplorer) is an OpenSource variant of AVS with similar fea- 
tures. It comes with hundreds of built-in specialized func- 
tions. One can contribute with new components by follow- 
ing an API. The new component will become available af- 
ter recompiling the application. Outside data visualization 
commercial solutions dominate the market. SimuUnk is a 
software package for modeling, simulating, and analyzing 
dynamic systems. It provides a GUI for building models 
as block diagrams, using drag-and-drop mouse operations. 
One can also customize and create ones own blocks. Lab- 
VIEW is a "program development application". It provides 
a graphical programming language, as opposed to a text- 
based language, used to create programs in a block diagram 
form for data acquisition and presentation. IRIS Explorer 
and the associated numerical and visualization libraries is 
another attempt for a tool to increase productivity. 

In the realm of open-source visual programming there 
has been much less progress, but that is mainly due to the 
fact that the attempts are rather new. Based on a language 
interoperability tool called Babel, a couple of projects have 
been started, each producing, for the moment, a rudimen- 
tary GUI. SciRun2 is a more mature computational frame- 
work that recently has turned to Babel to increase its con- 
nectivity |7|. 

In spite of the availability of the above and other high 
quality tools a solution that would deeply penetrate the com- 
munity is still lacking. The reason is either being of limited 
scope, e.g. only visualization, or technically too challeng- 
ing for component authors with natural sciences or engi- 
neering background, or because of not supporting the tradi- 
tional ways of coding, or too expensive, or not supported by 
the majority, or all the above. COMODI is trying to fill in 
the above gaps. 



3 The COMODI GUI 

As suggested in the introduction the user side GUI is 
not the part that would bring about the envisioned break- 
through. Even if quickly acquiring the support of a large 
user and developer community, the GUI will still have to 
go through a long maturing process before it can close up 
on similar commercial VP environments. However, it can 
significantly limit the impact of COMODI if the design of 
the very first release doesn't follow such clear principles as 
the zero effort threshold commandment on the component 
development procedure 1 1 1 . Below we formulate a few re- 
quirements that are essential for COMODI to be appealing: 

• the learning curve for exploiting the capabilities of the 
system should be smooth: The interdependence of the 
accessible features and the level of expertise required 
for using them should be free of abrupt thresholds. A 
careful design of default behaviors and wizards is es- 
sential; 

• it has to offer all the benefits of high level program- 
ming yet should keep low-level control at easy reach: 
The user should be able to set the level of abstraction 
that is wanted. Visualizing connectors, breakpoints 
and other "administrative" components should be pos- 
sible but optional; 

• self-explanatory and easy to use: the inspection of 
components' interfaces should not require more than 
a couple of clicks. Tooltips, status bar texts and alike 
for the documentation of the component, its ports, and 
the ports' parameters should be ubiquitous; 

• highly-customizable: components should look similar 
enough so that using them would always be obvious 
but allow for customization both by the author of the 
component and the user. Similarly to controlling fonts 
in a browser, users should be able to override certain 
author settings. Many will prefer to see features simi- 
lar to existing VP environments. 

We consider that sequentiality, an idea that is strongly 
imprinted into scientific software developers' vision, must 
also be suggestively represented by the relative arrangement 
of components in a project graph and the location of ports 
on a component. In the early stages of the maturing process 
of COMODI, the programming interfaces of components 
will likely be designed at will, without respecting any stan- 
dards. Hence, during the assembling process the user will 
have to manually match provides and uses ports, and check 
the compatibility of the connected ports at the level of each 
argument. Therefore, the inspection of all ports and param- 
eters therein will have to be assisted by GUI elements made 
as handy as possible. 
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In perspective, we expect that a reuse oriented commu- 
nity will enforce standards which not only that will speed 
up considerably the manual assembling process but will 
open the way to automatic interface matching (search — > 
(down)load ^ paste configure) managed by AI modules. 

4 Representation of components and ports 

For the first release of COMODI, components are re- 
garded as the lowest granularity units of code, namely, func- 
tions and procedures. On the left-hand side of a component 
we have its provide ports while on the right its uses or call 
ports (see figure^. We shall term the two as the provide and 
uses side, respectively. Data flows in/out via the black/white 
ports. They represent entry and exit points of regular func- 
tion calls. Provide ports are connection points to the parent 
component located one level higher in the call tree. Con- 
versely, uses ports connect the component to its children, 
one level deeper in the call hierarchy. This representation 
is fairly intuitive as it maps almost directly to the source 
code wherein the body of a function contains lines with the 
invocation of other functions. 
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Figure 1. Component classification 

As a general rule the diversification of component rep- 
resentation should be fully supported in order to assure 
guides for the eye, that is, a better overview of large project 
graphs that extend over several screens manageable only 
via scrolling and zooming. The difference in the compo- 
nents' functionalities should be reflected in their appear- 
ance. Therefore we suggest that all uses ports should be 
displayed. Many components will still seem alike but this 
simple rule will confer certain variety to the outlook of com- 
ponents. Statistically speaking, there will be a correlation 
between the weight of a component in terms of offered ser- 
vices and its geometric size. In perspective, the recom- 
mended solution is a skin repository referenced by compo- 
nents and downloaded by the framework upon request. 

In order to manage connections the user should be pro- 
vided with interfaces that make the inspection of all compo- 
nent, ports and parameter properties straightforward. Figure 
|2|presents an interface containing most relevant information 



pertaining to a component. The window can be accessed by 
double-clicking the component in the project graph. 
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Figure 2. Graphical user interface for inspect- 
ing and setting component properties 



The Uses ports section displays the names of the ports as 
referred to by the author, leaving the actual identity of the 
child components to the user to decide. Double clicking one 
of the uses ports from the list would lead to another infor- 
mation window dedicated to that particular port, as shown 
in figure |3] Direct click on a uses port in the project graph 
opens up this very same window. Future versions will al- 
low linking of complex data types in the parameter lists to 
corresponding documentation windows. 

4.1 Mandatory and optional ports. 

In the reuse oriented future, components should not sim- 
ply expose some "dangling bonds" or, on the contrary, be 
completely autonomous. They should allow for as many 
uses ports as possible but in the same time provide from 
within the deployed package a default connection for all 
these ports. For instance, a molecular dynamics compo- 
nent should allow the user to re-define any of the two- 
and three-body interaction functions between chemical el- 
ements. On the other hand, a component handling fc-body 
interactions of n chemical elements would be completely 
useless if n!/(n — fc) !fc! different functions would need to be 
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Figure 3. Graphical user interface for inspect- 
ing port properties 



wired up before using it. Figure |2l demonstrates a possible 
alternative for handling this issue. For most, ideally all uses 
ports a default connection will be defined, i.e., an exported 
or private function within the deployed component. Using 
the checkboxes the user selects those ports that are to be 
connected to user-defined external components. Those that 
are unchecked use the default internal references. Inactive 
checkboxes represent the case for ports that do not have an 
internal default connection therefore are always displayed 
on the right side of the component and user provided con- 
nection is mandatory. Another possibility is to use external 
components as default connections within the boundaries of 
a composed component. 

5 Representation of a project 

A project is a graph of interconnected components, as 
shown in figure 0] Connection means data flow via func- 
tion interfaces from the output of one component to the in- 
put of another 1 8 1 . We can identify two different types of 
communication: a horizontal client-server type of a com- 
munication entailing a change in the call depth and a verti- 
cal pipe&filter type entailing data transfer between siblings. 
C3 - C3.2, exemplifying a client-server communication is 
the direct representation of the pull model for module com- 
munication. It consists in a function calling another, which 
returns data to the former. This is basically the only model 
for communication in low-level languages such as C or For- 
tran. On the other hand, vertical calls (C3.1 - C3.2) im- 
ply the piping of an output into the input ports of another 
component. This push model, is not directly supported by 
low-level languages. However, as we shall show below it 
can be transformed into equivalent client-server communi- 
cation. Disregarding this aspect the structure is tree-like. 
At this stage, branching and loops are concepts that are un- 
known to the project. All decisions pertaining to the order 
of child calls are made runtime and inside the components. 




Figure 4. Recommended representation of a 
project in the frameworl< COIVIODI. The com- 
ponents reach execution state starting from 
left to right, bottom to top. In this case the 
order is: framework (CI), C2, C3, C3.1, C3.2, 
C4, C4.1 



Hence the order of calls, the way it is suggested in figure 
0] is not strict. It is rather meant to suggest the position of 
the corresponding call point in the source code of the com- 
ponent. In perspective, the extraction of non-tree elements 
(branches, loops) from inside the components out into the 
flow diagram is conceivable with the help of specialized 
connector components. 

In order to allow smoothless transition between GUI ver- 
sions or even completely different environments - just as 
different windows managers can be plugged into the same 
X Windows system - COMODI should come with a basic 
DTD that describes the representation independent state of 
the system, e.g., topology of the project, execution state, etc. 
All GUIs come with their own DTDs that are extensions of 
the representation independent one. In case a GUI encoun- 
ters a project or a component with an incomprehensible de- 
scriptor file, relying on the services of the framework, it will 
find the "greatest common denominator" in the DTD inher- 
itance hierarchy available online, transforms the descriptor 
file accordingly and then proceed with the rendering. 

6 Connectors 

Connectors are simple components mediating dataflow 
between "real" components. This indirection can be due to 
reasons such as the necessity for satisfying certain syntacti- 
cal requirements of component wiring, splitting up outgoing 
dataflow and sharing it between child components, merging 
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incoming dataflow, broadcasting the same data to several 
components, etc. For a review on connectors see |^| and ch. 
10 in LIOJ . 




a) b) 



Figure 5. Translating between pipe&filter and 
client-server communication via a connector. 

Here we only want to single out one particular type of 
connector Above we noted that pipe&filter communication 
is an abstraction that can be realized by transforming it into 
two client-server calls via a connector. Figure |5^ and (Sj? 
illustrates this transformation. As an additional feature the 
GUI can display the connector for those who are keen of 
seeing a perfect tree hierarchy or hide it if preferred. While 
this connector can be managed automatically, most of the 
others will need specialized user interfaces for manual con- 
figuration. 

7 Conclusions and outlook 

In spite of a great deal of similarities with existing vi- 
sual programming environments, the special scope of the 
COMODI project endows the user framework's GUI with 
features that are not common in other solutions. The sug- 
gested graphical elements and behavior are intuitively in 
harmony with the low-level programming paradigm. Once 
released to the public domain, a fast development of the 
GUI is expected. Parallel to the development of the above 
presented GUI several others are expected to emerge target- 
ing restricted groups of computational scientists. Therefore, 
during the design process a special emphasis should be laid 
on defining proper interlayer communication interfaces. 
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